Large enterprises rely on vast amounts and diverse types of data for their operation—personnel data, financial data, accounting data, inventory data, capital equipment data, document management data, and more. Today, data is generally stored according to data structures referred to as a data schemas, such as XML and relational database schemas, these being a form of metadata. The term “metadata” is used to denote data about the structure of the raw data itself, and about the structures of other Information Technology (IT) systems such as applications, processes, middleware and hardware configurations. The raw data, which includes actual data about specific personnel, for example, or specific pieces of inventory, is referred to as “instance data.”Thus, for a data store having the structure of a relational database, the metadata describes the tables and their columns to be populated with data, and the raw data, referred to as instance data, is the actual data stored within the tables and columns. Similarly, for a data store of XML documents, the metadata describes the XML complexTypes and their XML elements, and the instance data is the actual data stored within the XML documents. Each data store is referred to generically as a “data asset.”
Types of metadata include inter alia data schemas such as relational and XML schemas, source code, architecture models such as information models and process models, operational metadata regarding usage of applications and up-time, hardware inventories and configurations, service level agreements, and IT budgets.
It is common for large enterprises to have thousands of different data assets, each with a unique schema; i.e., thousands of different metadata descriptions, within their IT. For example, financial data may be spread out over several different relational databases, personnel data may be spread out over several different XML document stores, and inventory data may be spread out according to several different Cobol Copybook definitions.
In order to describe all of the different types of enterprise IT assets, including inter alia data assets and applications, a metamodel is used to model the entire repertoire of IT asset types. Such asset types include inter alia relational database schemas, XML schemas, COBOL Copybook definitions, Java applications, Engage Transform and Load (ETL) middleware and the structures associated therewith. A “metamodel” is a model for metadata, and describes the types of assets within the enterprise IT, and their inter-dependencies. Actual metadata itself instantiates the metamodel.
The three levels of data—instance data, metadata and metamodel, form a data hierarchy, wherein the structure of each level of data is described by the level above it. The three data levels within the data hierarchy are denoted by M0 (instance data), M1 (metadata) and M2 (metamodel). More generally, M0 includes instance data, messages and specific interactions; M1 defines actual IT structures, such as specific schemas, interfaces and inter-dependencies; and M2 describes types of structures and cross-references of IT.
In order to enable efficient use of a rich and configurable metamodel, a system is needed that supports (i) metamodel editing; (ii) classes, properties, inheritance and multiple inheritance within a metamodel; and (iii) industry standards such as Meta-Object Facility (MOF™) for structure of the metamodel, XML Interchange (XMI™) for import and export of metadata, and standard metamodels such as the Common Warehouse Metamodel (CWM™) and the DMTF Common Information Model (CIM™). MOF™, XMI and CWM™ are standards developed by the Object Modeling Group (OMG®); and CIM is a standard developed by Distributed Management Task Force, Inc. (DMTF™).
While the prior art includes flexible metamodels such as MOF-compliant metamodels, which flexibly define the structure of metadata, metamodels have not been used to describe specific rules which metadata must obey. Therefore, metamodels have hitherto had limited use in the detailed governance of IT.
Furthermore, although there are standard languages such as MOF for specifying metamodels, in reality sources of metadata currently have their own metamodels, making it difficult to accumulate metadata from different sources into one overall metadata model of enterprise IT.